KEP 88: Lifecycle Toolkit - Adding Instances to KeptnApp #90
Conversation
Signed-off-by: Thomas Schuetz <[email protected]>
thschue
requested review from
AloisReitbauer,
christian-kreuzberger-dtx and
johannes-b
as code owners
Signed-off-by: Thomas Schuetz <[email protected]>
| - An instance has to be specified on the workload and application level | ||
| - If an instance is not specified, the lifecycle toolkit will assume that there is only a single instance of the workload or application | ||
| - If an instance is not specified on the workload level, the lifecycle toolkit will lookup the corresponding application and use the instance specified there | ||
| - Properties of an instance are defined in the `KeptnApp` resource |
There was a problem hiding this comment.
I would also add the propagation of this info into the span via OTel attribute
| - Properties of an instance are defined in the `KeptnApp` resource | |
| - Properties of an instance are defined in the `KeptnApp` resource | |
| - Properties of an instance are stored as attributes in the generated Spans |
|
|
||
| ``` | ||
|
|
||
| The `instance` property is used to specify the current instance of the application. If this property is not specified, the lifecycle toolkit will assume that there is only a single instance of the application called "single". |
There was a problem hiding this comment.
| The `instance` property is used to specify the current instance of the application. If this property is not specified, the lifecycle toolkit will assume that there is only a single instance of the application called "single". | |
| The `instance` property is used to specify the application's current instance. If this property is not specified, the lifecycle toolkit will assume that there is only a single instance of the application called "single". |
There was a problem hiding this comment.
I would suggest another name as default:
| The `instance` property is used to specify the current instance of the application. If this property is not specified, the lifecycle toolkit will assume that there is only a single instance of the application called "single". | |
| The `instance` property is used to specify the current instance of the application. If this property is not specified, the lifecycle toolkit will assume that there is only a single instance of the application called "main". |
| The `instance` property is used to specify the current instance of the application. If this property is not specified, the lifecycle toolkit will assume that there is only a single instance of the application called "single". | |
| The `instance` property is used to specify the current instance of the application. If this property is not specified, the lifecycle toolkit will assume that there is only a single instance of the application called "default". |
| spec: | ||
| instance: <name of the current instance> | ||
| [...] | ||
| instances: |
There was a problem hiding this comment.
This schema would require having the same KeptnApp with the instances structure across (potentially) multiple repositories. The benefit of this proposal is that we have a complete overview of the instances' tree.
I suggest only storing the partial view in each KeptnApp, i.e., the next successors of the current instance. This way, if we want to add a successor to, let's say, production, we don't need to change the KeptnApp of dev, staging, etc.
As a drawback, this won't allow a complete overview in the KeptnApp definition and push this into the Observability platform via trace.
|
Hello and thank you for your comments!
|
|
+1 |
| repository: <git repository> | ||
| branch: <git branch> | ||
| path: <path to the manifest> | ||
| reposecret: <secret to access the repository> |
There was a problem hiding this comment.
TC discussion: here we could use secretName and secretKey to fetch a K8s secret.
Signed-off-by: Thomas Schuetz [email protected]